home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_tj / text0017.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  8.2 KB  |  177 lines
  1. Hi,
  2.  
  3. >Yes, it can hardly hurt to contact iD in any case. I'd be very surprised
  4. >if they have any objections to us writing this program. After all it's not
  5. >based on any of their sources, it's unlikely to behave exactly the same and
  6. >it's for a computer they might not even know exists.
  7. Yes, they seem to be quite cool in fact. But they just don't want any other
  8. people to make money with THEIR work, which is quite normal.
  9.  
  10. >> Perhaps something like WAD, or BAD MOOD, I don't know. It's not very
  11. >                                 ^^^^^^^^
  12. >I like that one!
  13. Laurent thought about MOOD. Good idea, heh?
  14.  
  15. >No, but it'd be more comfortable to have at least a working title,
  16. >especially for discussions on newsgroups etc.
  17. OK, let's call it MOOD for short.
  18.  
  19. >with almost the same thing anyway IMO. We can't do the cheating that
  20. >everyone else is using with this kind of programs for the Falcon since our
  21. >datastructures and their behaviour is already defined.
  22. Exactly. So the program should be more or less the same, it's what you
  23. think? And Laurent seems to be enthousiastic about the improvements he can
  24. bring. So...
  25.  
  26. >I believe that kind of approach is very dangerous. The DVIEW engine for
  27. >example runs _much_ faster when the part of the map that's in front of you
  28. >is simple. Unfortunately, that's not very common in DOOM.
  29. Right.
  30.  
  31. >Well, Laurent seems to think (see bottom) that optimizing DVIEW in assembly
  32. >will do wonders. I'm not that sure, though. Running the rendering on the
  33. >DSP is quite another matter, but then there's the problem of what to
  34. >transfer CPU<->DSP and how.
  35. I think we can't tell before we do some experimentation. I'm currently
  36. trying a mapped polygon routine on my own (that is, a quadrilateral polygon
  37. with vertical sides). When it's finished, I'll ask Laurent what he thinks.
  38. In fact, I don't know how he plans to do it. But I have to try
  39. independantly, just to see what can be done with the 68030 alone.
  40.  
  41. >Before any real work is started I suggest that we profile the rendering
  42. >engine as far as possible. So far it seems to me that the biggest speedups
  43. >will be done at the highest levels (map clipping and projection).
  44. You mean that the texture mapping is standard enough stuff and that the real
  45. improvements will be to decide in the fastest possible way what to draw, and
  46. what not to draw?
  47. I agree with this.
  48.  
  49. >I'm looking forward to hearing about it.
  50. Nothing revolutionary I think about my texture algo. But in fact, I don't
  51. know what is the method used by others. I want to test my ideas and then
  52. confront them with what exists.
  53.  
  54. >I still haven't made the general release of MGIF, but that's not taking much
  55. >time at the moment. Then there is another project that I've had not done
  56. >anything about for a couple of years and...
  57. Yes, the same for me. A lot of ideas, but not enough time...
  58.  
  59. >I'm a doctoral student researching some new ideas in the field of VLSI
  60. >clocking and synchronization. The work also includes about 20% teaching,
  61. >so I don't expect to get my PhD before the next millenium (if I do indeed
  62. >continue that long and isn't kicked out).
  63. So you're in computers to the throat!
  64.  
  65. >In my free time (when I'm not programming) I read a lot (well, at least
  66. >it's 10-20kpages/year) of fiction, mostly thriller and fantasy. I also
  67. >play the trumpet in a big band and cornet in a brass band. I also took up
  68. >fencing recently.
  69. Fine. I read a lot, too. I used to read a lot of SF. But now I try to read a
  70. lot more "classical" litterature. SF is fun, but not so interesting...
  71. I was very good at fencing when I was a kid, but I quit when I was 17. I
  72. often play with the idea of digging my old sword out of the attic.
  73.  
  74. >What are you doing yourself? I recall your work/school had something to
  75. >do with physics.
  76. Yes, I'm in the third year of my PhD. I teach, too (about 4 hours a week).
  77. And I'm doing physics. More precisely, mathematical physics, algebra, field
  78. theory, things like that.
  79.  
  80. >---- here follows some email I've exchanged with Laurent ----
  81. >I've incorporated some simple statistics collection in DVIEW which gave
  82. >some numbers that are interesting for the optimization. The figures are
  83. >approximate averages over more than 200 drawings from five different levels.
  84. >
  85. >Function    Calls    Internal loops
  86. >                       (1)     (2)
  87. >Addfloor     150       1100
  88. >Addwall       50       1700
  89. >Coldraw      600
  90. >Rowdraw     1000
  91. >Drawnode     200
  92. >Drawssector  100        300
  93. >Loadseg      150       1600    400
  94. >
  95. >Time for
  96. >structure setup:   0.28
  97. >actual drawing:    0.08
  98. >chunky to planar:  0.11
  99. OK. The structure setup is what takes the largest amount of time. Of course,
  100. no texture, but it shows that you're right in saying that this is the part
  101. to work on.
  102. Is Rowdraw used only when drawing floors? I think our program will certainly
  103. not have mapped floors. Or as an option for people having F040s or things
  104. like that?
  105.  
  106. >I am, however, almost certain that the necessary data from the .WAD can
  107. >be held in the DSPs RAM. The original 'structure engine' used a number
  108. >of large arrays, though, which would not have fit. Fortunately, I believe
  109. >I have found a way to get rid of almost all of that.
  110. What is it? And has all this data to be kept at the same time?
  111. Anyway, I have to take a serious look at the source of DVIEW. I haven't had
  112. the time to do it yet.
  113.  
  114. >Finally, I've given some thought to the sprite drawing and discovered
  115. >that it will be even more tricky than I previously thought. The clipping
  116. >against walls and floors will be quite difficult. Perhaps even to such
  117. >a degree that the extra arrays I mentioned above must actually be
  118. >re-inserted, which would be very bad.
  119. Yes, because there is probably no other way to draw them than back to front.
  120. So you have to keep track of the coordinates of the transparent polygons of
  121. the ssectors. Is that it or am I completely out of the point?
  122.  
  123. >Yes, the maze is of course the more important part, but I worry that
  124. >we'll optimize away the stuff that makes the sprites possible.
  125. >I'll stop thinking about that for the moment, though.
  126. No no! I think you're right. We have to keep in mind that we have sprites to
  127. draw. And do the transparent textures bring problems?
  128.  
  129. >The engine itself is not big at all as you can see from the sources.
  130. >I think the sources compile to around 5-10 kbyte m68k object code.
  131. >The data from the WAD I've used was also of quite reasonable size.
  132. Excellent!
  133.  
  134. >My optimization consisted of drawing walls, floors and ceilings as
  135. >soon as they were available, which got rid of all three arrays mentioned,
  136. Yes, I thought the right way to do it was to draw all the solid walls of a
  137. ssector, and then, for each transparent wall, to look in the BSP which
  138. ssector is behind it, and draw this sector, clipped by the transparent wall.
  139. Then, when returning, draw the transparent or semi transparent wall. So you
  140. have to pile the coordinates of the transparent walls. Couldn't this data be
  141. used to draw the sprites, also? Or am I once more completely out of the
  142. question?
  143.  
  144. >I've heard that SNES DOOM has no floor or ceiling. I'll try that out.
  145. Well, even so, you've got to draw a filled polygon...
  146.  
  147. >******************************************************
  148. >I've spent far too much time with DVIEW, so I'm going to leave it as it is
  149. >for now. It simply refuses to do as I want...
  150. What do you mean?
  151.  
  152. >For good examples of the bugs, go into the room directly on the left
  153. >in the first level and look at the top of the stairs. The problem there
  154. >is that the wall outside is drawn on top of rest of the room. The
  155. >secret door near the end of the level is an example of the 'transparancy'.
  156. >If you can fix those bugs, I'd be very happy.
  157. I'll also try to understand this.
  158.  
  159. OK.
  160. Well, Bye. I'll keep you informed. But I have to admit I'm very impressed by
  161. the speed at which you achieved so much.
  162.  
  163. Regards, 
  164. Bertrand
  165. +-----------------------------------------------------------+
  166. |Bertrand Le Roy      |A Darwinian theory of Gravitation:   |
  167. |bleroy@ccr.jussieu.fr|In the beginning,  mature apples fell|
  168. |tel. 44.27.72.95     |in all directions. But only the trees|
  169. |fax. 44.27.72.87     |whose apples fell down have survived.|
  170. +-----------------------------------------------------------+
  171. |Laboratoire de Gravitation et Cosmologie Relativistes      |
  172. |Universite Pierre et Marie Curie, tour 22-12, 4e etage     |
  173. |4, place Jussieu, 75252 Paris Cedex 05                     |
  174. +-----------------------------------------------------------+
  175.  
  176.  
  177.